Jason Knight 0:00 Hello and welcome to the show and an episode where we talk about embracing some of the messy bits of day to day product management, and help practice makes perfect, or at least better. Speaking of practice, this episode is sponsored by Skiplevel. Now ask yourself as an honest question, do you struggle with communicating with dev teams and understanding technical terminology and concepts? On episode 98 of this podcast I hosted Irene Yu, founder of Skiplevel, an on demand training programme that helps professionals and teams become more technical in just five weeks, or without learning how to code. You can learn the knowledge and skills you need to better communicate with devs and become more confident in your day to day role with the Skiplevel program. So, if that sounds interesting, check out https://www.oneknightinproduct.com/skiplevel to find out more, check the show notes for more details. All right. So technical skills aside, what are some of the other core skills of product managers? And why does it feel that product management isn't always quite how the book seemed to suggest if you want to find out to make more of an impact as a product manager wherever you are, stick with us on One Knight in Product. Jason Knight 1:09 So my guest tonight is Matt LeMay. Matt's a former touring musician and music journalist and product management guru says he hates long PowerPoint decks. But the joke's on you, Matt, because I use Google Slides. Matt's passionate about fashion is always well turned out. But he's in no mood to dress up the realities of product management and wants us all to see it for what it is unfiltered and untouched. He's doing this as a product management consultant, coach and renowned author of Product Management in practice, a practical tactical guide for your first day and every day after. Well, he's obviously not had some of the days I've had. Hi, Matt, how are you tonight? Matt LeMay 1:39 I'm doing well. Thanks. How are you? Jason Knight 1:40 I am doing wonderfully well and looking forward to deconstructing product management and hopefully reconstructing it in a slightly more attractive form. But let's see how we get on. So first things first, you are a partner, principal product management consultant at Southern compass. That's correct. So have to ask who is sun compass? And what are you doing for them specifically these days? Matt LeMay 2:00 Sure. So southern compass is a collective consisting of myself, Tricia Huang, and Sonny Bates. I'm very lucky to work with two powerhouse geniuses. Sonny's background is primarily in recruiting and network building, she is probably the least transactionally minded person I know and connecting people to other people, which I think is truly a superpower she sees every opportunity long before other people do, has been at the vanguard of a lot of things. And Trisha Hwang is an ethnographic research expert, who studies how people use technology. And I was familiar with her work before we started working together. And we were doing work that overlapped in interesting and not terribly obvious ways and decided to pull together into a kind of consulting collective with the idea that we would be stronger if we had the opportunity to work with each other and share ideas with each other and continuously learn from each other. So here in the UK, I am primarily primarily doing my own little projects, but always having that base of support and collaboration to learn and grow from. Jason Knight 3:10 So would you say it's fair to say that compass isn't just in quotes, product management consultancy, but it's a bit of a wider thing, and almost like a collective of people that can support each other. But like you say, you're kind of you're not all just doing exactly the same stuff and working with the same clients? Matt LeMay 3:25 Exactly. I mean, I would say product management isn't just a product management. book about that. Yeah. So I think the expansive and connective nature of the collective is true to the expansive and connective nature of the work that all of us do. Jason Knight 3:42 But for example, if you've got an ethnographer in the group, then what's an example of a time that that's helped you in your product management, consulting? Matt LeMay 3:50 Gosh, so Tricia, train me up and how to do qualitative research. Yep. And I am so grateful she did, because I will never forget the first interview we did, where she said, You know what, Matt, I'm gonna let you leave. And then we'll retrospect afterwards, and we'll see what went well, and what could be done better. And I made every mistake you could possibly make. I made the interview about myself right down to like ordering the food I wanted, rather than asking the interview subject what they wanted, I asked leading questions. The second they asked a question where I thought that was the answer. I wanted them. Oh, that's great. That's exciting. And she let me make all of those mistakes. And then afterwards, very generously helped me see why those weren't the right ways to do things. So not only did she train me and how to do research, she also trained me and how to train product managers to do research, and a lot of the work I do now kind of building bridges between researchers and product managers. One of the first things I tell researchers is you have to let people do bad research before they do good research. And if you're going to try to somehow preempt bad research from ever taking place, you are going to stay in that game spin posture for as long as research is being done in your order. organisation. So I think back to that experience a lot. That's an example of how, you know, folks who are really confident in their work are able to let other people do that work badly, and then show them a better way rather than trying to stop them from doing that work at all. Jason Knight 5:17 Reminds me of my dad watching me do DIY gamely trying to read patch a bit of wall or something like that, sitting there watching me with a pained look on his face for a while and then eventually just taking the tools and fixing all that for me properly. So maybe not quite the same, but definitely the same sort of area. But before we talk about product management in practice, I wanted to dig into your own journey into product management just a little and find out how you got to where you got to today at the port, not necessarily the summit, or what are the summits of Product Management? What was it that got you into product management in the first place? Matt LeMay 5:51 A Google search for a job in tech at programming. Okay, salary. That's Jason Knight 5:58 your gone. Okay, salary. Jeez, Matt LeMay 6:00 yeah, I wasn't very, I wasn't terribly ambitious. I was I think 26 At the time, Jason Knight 6:04 I dream of an okay salary. Matt LeMay 6:07 So I was working, I got my first job at a tech startup as an API evangelist while doing developer relations. And this was a contract gig, I was invited to come on full time, I didn't know what title to ask for. So I did the aforementioned Google search. Product manager came up and I went to my boss and said, I want to be a product manager. And he said, Sure, I don't care. And 12 and a half years later, here we are. Jason Knight 6:34 But that sounds like actually, to be fair, I think you'd call down the book as well, that that's not something that was a particularly structured role that you're going in for and something that you maybe had to work out a little bit what that even really meant. And you said also in the book that you wish that you'd had your book back when you started, which obviously, you didn't, because you haven't written it yet. But that does beg the question that how did you get started? Like, were there other books that you read? Were there mentors or other people in the community that you could reach out to? Sounds like maybe your boss wasn't necessarily the person to fully define that for you. So how did you get in them? How did you get started? Matt LeMay 7:07 Sure. I mean, I wish I had been better about seeking mentorship and guidance from other people. I think at the time, I was still a younger and more defensive person. And I really wanted to project that I had some idea what I was doing. So I just Googled every short article I could read, tried to absorb all of it as quickly as possible and kind of showed up. On my first day to work. I kept this in the second edition with the something to the effect of the unearned swagger of a young man who had many things very quickly. And I really tried to look how heavily unqualified this I tried to pretend I didn't even successfully pretend I had some clue what I was doing. But I had no idea what I was doing. And what I did find myself doing had very little to do with the articles I had read, which left me convinced that I was doing the wrong things, on top of doing those things poorly. So it was a very stressful, I'd say my first year in particular product management involve a lot of sleepless nights a fair amount of crying. And I don't think I was intrinsically confident nor humble enough, because confidence and humility are certainly not opposites of each other. I was neither of those things enough to seek the guidance that probably would have been most valuable to me. So I was happy to try to encapsulate it in book form, which is more more palatable to those of us who get very nervous asking other people for help or guidance directly. Jason Knight 8:42 But that's an interesting point, right? Because writing a book is something that you touched on it yourself there, you have this kind of maybe naive confidence when you started out wanting to join, make the best of it and being a little bit to either proud or nervous or scared of asking for advice, or some mixture of all of those things. But writing a book is itself a statement and the first edition of Product Management Practice I think came out in 2017 or so. So that's correct. It was a few years after you started, but it's still a big step. So what was it that made you feel that it was time to go and write a book aside from wanting to get your learnings down? I mean, lots of people want to get their learnings down, but actually getting those down in a structured way and having the confidence to release that and publish that and try and get it in front of other people. Was there like a moment where you thought this book has to be or was it more of a an iterative process that just kind of happened as you went along? Matt LeMay 9:32 Yes, I think it started more iteratively a friend of mine invited me to give a talk for a roomful of newsroom product managers and I gave a talk called the past and future of product management where I just kind of walk through where I saw the discipline going and through some of my opinions out there. I wrote that up as a medium article because my friend pointed out that I was shifting on my feet a lot in the video recording and it looked very strange. I had not learned how to command to stay Ah, where whatever it is I do too, or with a stage. And so I just wrote it up as an article and it got a lot of traction. I was really surprised at how much it seemed to resonate with folks. So I had met some editors at O'Reilly. And I pitched them on the idea of a very voici and opinionated book about product management. They were open to it. And then the moment where it really crystallised for me funny enough, I met with somebody in New York, I was living in New York at the time. And he was like, Well, what's your hook? what's the, what's the, you know, the big idea. And I said, you know, I just want to dump out everything I think would possibly be helpful to a product manager and one book, he said, You can't do that. That's not a book. You have to save something, you can't give away everything you think is valuable in one place, you need to save something for yourself for future books and for insulting for other purposes. And in that moment, for part of me, the part of me that, for better or worse, likes to keep myself in check, and feels some need to give away too much of myself was activated, let's say and I said, Oh, that's exactly. Weirdly, this is exactly what I need to, I do want to write a book, which is just everything I want to give everything away. Like I want to just put everything I possibly can, that could possibly be helpful to a product manager in this book. Because product managers need a lot of help. And I made a lot of mistakes. And if I can spare somebody else, making those mistakes, or at least help somebody get into that cycle of reflecting on those mistakes a little bit more quickly and a little more openly. them I can see this book as a success. So that weirdly, was was the moment where I was like, Okay, now I know exactly what I'm gonna do. Jason Knight 11:41 Oh, there you go. The origin story originated right there. But one thing I will also say as an aside, is I can vouch for your stage style, and the fact that you can go out there and be fairly contrary. But in a really constructive way. I think I saw you a couple of times on stage. And it's been really interesting watching you kind of take almost I don't know if it's a deliberately contrarian position or just your sort of punchy style. But just it's really interesting watching some of the other people I think it was a panel like some of the people that are on stage, have you kind of like, almost taken aback by the opinions aren't the same as everyone else's opinion. So I think it's good. We need more electricity within Product Management. Matt LeMay 12:19 Thank you. I mean, my inspiration, funnily enough, is Alan Watts. If you ever watch any other videos of him on YouTube, there's just this delicious and deep knowledge and this joy and sharing that knowledge. Obviously, Alan Watts was not talking about product management, but talking about existence and Zen Buddhism. But there's something about the way he approaches things that, that in both content and style that I aspire to, there you Jason Knight 12:47 go get those boxing gloves on. But now we're back with addition to have the book, yes, revised and expanded. So it says on the cover. So, in general, what's changed in version two of the book, and why should people buy it? Matt LeMay 13:02 Sure. So a couple of things have changed. You know, one of the great and ever humbling things about product management is the longer you do it, and around it, the more your own opinions change. Yep. So there were a few things in the first edition that I think I had simplified too much, frankly, especially this idea that having good goals will help you make good prioritisation decisions. This was frankly, just the limitations of my own experience. I have worked mostly with smaller companies where you could have a product manager and a CEO setting goals quarterly together. And the more I've worked with enterprises and companies where there's this complex layer cake of goals that I speak about in the book, the more I've just come to embrace and accept the irreducible complexity and the fact that there will always be some tension and some misalignment and this idea of achieving a state where goals and objectives are aligned perfectly within the organisation. It's a nice idea, but it's rarely ever a state that's achieved. So it was really important for me to go back and expand upon that a little bit. And I think I got, you know, more. I don't want to say more argumentative because it doesn't feel terribly argumentative. But I got more direct and stating that some of the orthodoxies of product management world, particularly around hustle culture, and the idea that you have to work 60 hours a week to be a product manager, that these are not ideas we should hold up or support in the product management community. In part because these are things I heard when I did a lot of interviews. This time, I heard from folks who had struggled with burnout who had made the decision to put in those 60 hour weeks at the expense of their own mental health or the health of their family and their happiness. So I think it was important to me to speak to some of those things more directly now that, you know, I think I've gotten to a place thankfully where I feel a little bit more comfortable stating some of these things more directly and challenging some of these orthodoxies with a little bit more credibility or momentum or whatever you want to call it behind me. Jason Knight 14:56 That makes a lot of sense and obviously that 60 hour thing for example something that has come up a bit on social recently people calling that out, I think actually Marty Kagan, who obviously famously wrote that and inspired recently was interviewed on another podcast. Yeah, those things exist. Apparently, he's interviewed on another podcast and tried to kind of reframe that and say that it wasn't necessarily an aspiration, but more of just a reality of what he'd sit in, but not something that he was promoting. So I think it is true that there's a lot of ivory tower thinking out there, like this is the way that the big tech companies do it. And this is just the way that it should be. And if you're not doing like this, then you have a bad product manager. I know you talk a little bit about bad product managers in the book as well, but more around the types of behaviours that they exhibit, which is, which is fair enough. But I think that whenever I get into these good bad product manager arguments, it's always like, it always feels like people are almost attacking the person versus the behaviours. They're like, Oh, well, you have a bad product manager, and you look at it and say, well, they're not a bad product manager, per se, they're just in a company that's not doing things the way that the good point, I might just say, and I think that reducing it down to that person is a bad product manager, I think is not a very friendly thing to do at all. Matt LeMay 16:04 I agree with that. And the one that's really been getting my goat lately, is the idea that if your company uses a certain framework, or defines roles a certain way, then you don't get to call yourself a product manager, or you're not a real product manager. I speak to this directly in my chapter, which really should just be called yelling about agile, because that's what it is at this point. But you know, I have heard people say, you know, if you're working in safe, you're not really a product manager. If your company does this, you're not really a product manager. And I hate that. Because for starters, what does it even mean? To really be me, these are all made up things to begin with. So I use this to make people feel bad about themselves. Yeah, but beyond that, you know, I know people who don't have product manager titles, who are project managers, or product owners, or Scrum Masters or whatever, who are doing phenomenal work, we're thinking strategically or having an impact. This idea that the constraints or the shape or the frameworks chosen in your organisation, would preclude you from doing this job well, is, in fact, given these frameworks, more power than a lot of folks who advocate for those frameworks. Yep. So I think, you know, that kind of magical thinking, if we're going to oppose it on one side, in terms of, you know, this magical framework will make you a good product manager, we also have to impose it on the other side, and say, you know, By that same token, this terrible framework will make you a terrible product manager, there's always good work to be done. There's always a move, there's always a step. I think the big theme that came up in the interviews I did for this round of the book was, I wish I had spent less time reading and my organisation for not doing product management, quote, unquote, the right way. Oh, yeah. And I just done the best work, I could, you know, focused on myself and my team and our customers and having a decent life as a human being on planet Earth. And I think that's so So, so, so important. Because even those big tech companies aren't doing product management, quote, unquote, the right way. They're just publishing, recruiting propaganda. So they can compete with the other big tech companies who also have challenges and constraints, and personalities and issues to deal with. Jason Knight 18:10 I think it's really interesting. And you touched on it just there as well, this idea that maybe the people that are advocating for these things are doing it more strongly in some ways than the people that wrote the books. And obviously, on the podcast, I've interviewed a bunch of people that have written some of those books. And every single one of those interviews at least, and to be fair, even in some of the books are kind of caveat in some of the advice with the fact that you know, this is somewhat hard. And, like, you look at things like continuous discovery habits, which obviously everyone loves these days, and it's a great book. But even within that book, and speaking to Theresa as well, like, She's not saying that this is easy or possible in certain situations, or that everyone's gonna get to do it. But at the same time, she's kind of put it out there as something that you should aspire to. Now, I guess the question, though, is, should we extrapolate this and say that actually, people should, for example, just read books like yours? Or do you think that there's a lot of value in reading these aspirational books that are out there and the kind of the best in class processes and methodologies and frameworks and ideologies, and all of that stuff? Like, should people still read those books, but just with a certain pinch of salt in their hand? Or should they just go to the more pragmatic books like yours? Now, there's Matt LeMay 19:21 something I said at the beginning of the second edition, which I really want to put out there, which is when I was reading back through the first edition of my book, there was a bunch of stuff I disagreed with, in my own book that I had had more experience, and I looked back over things and said, Well, that's oversimplifying it, or no, that's not quite right. And I hope people read my book and every other book that same way. Yeah, I think that it's a good sign when you read a book and you disagree with something because it means that you have experienced that is concrete enough for you to look at advice being presented as expert advice and say this might not apply to my situation. So you know, I didn't have people come up to me so People don't say, Well, I disagree with this thing. And I say, Great, tell me more I didn't used to, you know, it's taken me time to, to get to this, this point in my life and self concept in general. But I think that the best place to get is one where knowledge can only be helpful, not the interest just to say that anything you read about, you can extrapolate out something that you think might be interesting, or that might be worth trying, you know, where you could read the safe manual. And rather than being like, look at this stupid thing, like, it's not really agile, you could be like, Oh, this idea is actually interested in like, having these coordination points might be really valuable, or like thinking about value delivery in this way might be really valuable. I think the goal and reading these things is never to find a single correct way of working. And as you said, I think everybody who wrote these books would absolutely agree with that, that nobody is trying to position abstract knowledge is more valuable than practical knowledge. But in order to write a book, you need to abstract out the infinite variability of practical knowledge. Yeah, so I think I always tell people, like read everything. And don't take anything as gospel, read everything and think critically. Jason Knight 21:21 No, absolutely. Definitely a big fan of internalising as much as possible. And I think actually, it was a book, The Jeff Sutherland book about Scrum, which I think I listened to an audio book for my sins. And there was something in there, which I need to find if it's actually in the book, or if I just drempt it. But this idea that you learn the system, you master the system, and then you throw away the system, because actually, by learning the system, what you've done is you've internalised actually the core principles, I guess, have the system. And then you can adapt that to whatever situation that you need to be in. Rather than just sitting there as you see some people online on LinkedIn, sort of sitting there saying, Well, if you're not doing this, then you're not doing Scrum. And I guess the most important takeaway for me is, it doesn't matter if you're doing Scrum, doesn't matter. If you're doing Agile, you don't get any points for doing any of that really, what you get points for is delivering a good product that goes out and makes a lot of money and makes a lot of users happy, right? Like how you get there. It's important, but it's not the end of the world, or the be all and end all right. Matt LeMay 22:19 Now, and these are all made up things. So I wrote a book called Agile for everybody, which I still think is one of the better books about agile, but being an agile world to promote that book got so exhausting. Because you're boxing phantoms all around you, you're having these conversations about like, is this really agile is this really Scrivener? Like these are made up things? Like who cares? If it's working for your team, if it's helping you deliver better outcomes? Why, you know, I had people telling me, for example, you can't change the three questions at the daily standup, it's not allowed, you have to ask, like, well, I've worked on teams, where those three questions didn't help. And we change those questions. And it did help. So I mean, who am I going to believe right, my lyin eyes or the sacred text. And even the sacred texts in almost every case, as you pointed out, says, Look, if this doesn't work, change it. So I'm, I just don't want to waste any more of my life having having those arguments with people. It's, there's no point. Jason Knight 23:23 No, absolutely. But back in the day, I used to ask guests on this podcast of all played being a barbecue and explaining product management to some person that they bumped into over sausage, and had never heard of it before. But Your book goes into that in some detail. So I'm not gonna do the roleplay. But there are some things that you say like you call out and you have caught out in this interview as well, the fact that product management is a bit messy, there's no like, ISO definition for what a product manager is. And it's different, all these different companies, but you do talk about some core skills of product managers. And I use that word advisedly, because it's actually the acronym. So you've got a communication, organisation, research and execution. So why are those the four core elements of a product manager? And does it matter if PMS don't have all of them? Matt LeMay 24:10 Sure. So when I was developing this model, I actually developed it through some workshops I was doing, and I knew it was valuable, which is not to say correct, but I knew it was valuable. When I would ask people to self evaluate against these skills and get different answers from a lot of different people. Yeah, that's usually the sign that you've created a model where the options within that model are differentiated enough that it's useful as a mechanism for reflection. And I find this model again as the most models useful as a mechanism for reflection and when I work with organisations to operationalize it, sometimes we change it, we can change it to score to put strategy in there or change at facilitation and make a force or you know, I think execution as I describe it as really in some ways more about prioritisation, so we can make the corp model or the pork in French PRC model. If we prefer, sometimes organisation is confusing, and it's better reframed as operations. But I think the basic idea is that you need to be able to communicate what you're doing, you need to be able to organise our operationalized, create systems, so your team can work effectively, even if you're not in the room constantly. You need to be able to research, learn new information about your customer, your market, your users, all that stuff. And then you need to be able to execute, you need to be able to get stuff done, and prioritise what gets done, and do the things that actually matter. So if you can do those things, then I think the rest of it, you know, again, it varies from team to team from organisation to organisation. But I think, you know, if you can do those things, effectively, you're well positioned to do the work of Product Management. And to your second question, you know, no, I think part of why I like this model also is that these aren't skills that you have or don't have, right? These are skills that you are constantly developing, and levelling up. So you know, for me, communication is something I've, I've done for a long time, I give talks, I write books, I talk to people, learning how to create systems and organise is something I need to work on. You know, I had to literally be trained up in research, because I didn't know how to do it. Well, the prioritisation piece of execution. You know, execution doesn't mean you do everything, it means you do the things that are important. Learning how to do that has been a journey for me as well. So I think you never have or don't have these skills. You're constantly both developing them and defining what they mean in your particular context. Jason Knight 26:29 If we were to I'm not sure what word it would spell, but if we were to put technical skills in there as well, which is something that you see debated all over the place these days, like, Should product managers be technical? Or should they not? Like where do you stand on that? Matt LeMay 26:42 I think it depends. And I can say from my own experience, classic, classic, right. But but here's the thing, I think, you know, if you're working, again, if you're working in a system where you need to have a baseline of a certain set of technical knowledge to help your team make decisions, of course, you know, I'm not going to walk in and be like, No, that doesn't matter in your situation where it clearly matters. But speaking from my own experience, my technical knowledge I had going in, made me annoying more than it made me useful that Oh, yeah. Which is to say, I thought I could like hang with the developers and be like, Oh, I know how to write PHP. And they were like, whatever, we don't care. I think the ability to ask thoughtful questions to learn technical knowledge in context, is really valuable. So I tell product managers, like you can't dismiss technical things as over your head, you can say, Oh, I could never understand that. I'm not technical, you have to be curious enough to go in and say, Okay, this might not be my area of expertise. But I want to understand, I want to know more about how you do this work. If you can be open and curious in that way that in most cases, I think you can learn what you need. And you can learn it from the people you need to work with and learn from context, which is more valuable than doing what I did at first, but say, Oh, we're a Python shop, I should go read a bunch of books about Python and show up and impress the developers, which did not work. Jason Knight 28:00 It's very difficult to impress developers at the best of times, even if you're another developer, as I remember, from my days of being a developer, I remember getting sand kicked in my face by the cooler developers can't even imagine what it must be like if you go in there, half cocked. But there's also the tiresome old trope of CEO of product. And your book calls that out as well. It's been caught out by a number of people that PMS aren't really the CEOs of product, but you have to work with actual CEOs. And they have to work with senior stakeholders and subject matter experts within the company. And lots of PMS complain that they're getting micromanaged or that they're not empowered just because they're executing someone else's plan. And obviously, that dynamic does exist, there's been plenty of, or I've worked in places where that exists. But is there a way that PMS can make peace with their position in the organisation and work effectively with senior stakeholders rather than just immediately crying out that they're in a feature factory as soon as someone says that they should do something? Matt LeMay 28:56 Yeah. So that? That's a great question. I think, you know, when you're a CEO, you state some idea you have and everybody says, Great, we love it, we'll go do it. When you're a product manager, you state some idea you have pardon my language, everyone says Go fuck yourself, like immediately, everybody. It's a very different position where you know, on the one hand, people are incentivized to treat everything you say as a pearl of genius. And on the other hand, because you have no authority, you know, people are going to be sceptical people are going to ask you hard questions, people are really going to want to know that what you're discussing is important and valuable. And you're going to have to be able to present a case for that which doesn't really want to say present the case for that. You're going to have to give people the information they need to make the right decision. And this is one I've seen a lot of people using this kind of language recently about creating the conditions for good decision making no tongue collars been talking about this a lot. My friend salle de Silva has been talking about this a lot. folks have been basically saying that when you're a product manager, you're not going to be the final decision maker, your job is to create the conditions where good decisions can be made. And I will take this even one step further and say, you know, a lot of product managers I've worked with get really hung up on this idea of influence. They want to influence the important people, they want to create that, you know that they want to be whispering in the ear of the CEO, we want to be the CEO. And I think the only path to freedom and happiness on product management is to give up not just on decision making, but on influence directly as well to say, look, my job is just to create the conditions where the best possible decision can be made. I can't control other people's behaviour, I can't control other people's actions, I can't control the decision that the CEO is going to make. And beyond that, the See, he'll might know things I don't, the CEO might know that we're planning an acquisition, which is going to change our strategy, the CEO might know that there's some battle taking place between shareholders where we have to pursue one thing that we can't pursue another, at a certain point, you have to let go and trust that the people making decisions, even if they're not making the right decisions, they have their reasons for making those decisions. And you will not always know or understand all those reasons. But the things that you do know and you do understand it is your job to communicate as directly to those stakeholders as you possibly can. So when product managers company, they say, you know, I did everything I could to try to make this decision, and they made the other decision. I say, you know, if you gave that person, all the information, you thought they needed to make that decision as thoughtfully as possible. If you help them understand the trade offs that go into making that decision, if rather than arguing for what you think is the right thing, you said, here are three different options. Here are the trade offs and the benefits and the risks of each one, you've done your job. And you shouldn't be able to disconnect, go home, have dinner and sleep at night, knowing that you did your job. You can't control other people. You can't I gave a talk I'm really proud of even at two conferences now called you don't get anyone to do anything. Because people ask me all the time, how do we get executives to make better decisions? How do we get researchers prioritise the work? The researchers asked me how do we get product managers to care about research? And I was speaking at a an agile conference. And the first and only question I got was, how do we get executives to be more agile? And I said, you don't get anyone to do anything. And I got no more answers, that people were very unhappy with the answer, provided no more questions. That was it. So I thought maybe there's something here. But I think once you realise that you don't get anyone to do anything, even the idea of influence is probably an illusion, and probably an ego driven illusion that that provide the best information, you can help people articulate and achieve their goals, and then go home, eat a nice dinner, hang out with people you care about, and live a balanced life. That's really the best advice I can give people. Jason Knight 32:57 Oh, there you go. That's getting very profound there. But one thing that I've seen in the past as well as people who really want to be the decision makers be the influence. And to be fair, when I say that I've seen I've also earlier in my career been somewhat in the situation myself, like, you want to be the person that either influences or makes the decisions, you want to be that CO product or whatever it is that you're calling yourself, but you don't actually have any better ideas. No, your ideas are just that you should be making them. And you spend so much time either trying to defend that position or build up defences around yourself or doing research to continuously try to work out whether that's the right decision that you forget to actually make a decision, then you get surprised when the leadership of the company are like, well, we kind of want to make a decision now when they basically do this whole overriding hippo thing. But to be fair, could you blame them? Matt LeMay 33:48 No, I think you said something really important there, which is this idea of defending things, I have found that in my product management career, I have harmed everything I have sought to defend when I've sought to defend my team against executive interference. I've actually harmed my team, because I've disconnected them from organisational goals. When I've sought to defend my decisions against those who would question them, I've made those decisions worse, because decisions are made better by more information. And in my attempt to defend those decisions, I have shut out other information. And when I've sought to defend myself and say, look at all the great work I'm doing, I've actually made myself less effective and less valuable as a product manager. So I think one of the hardest things to really recognises that. By the time you find yourself in a defensive posture, you're already failing, you're already making things worse. That's one of the one of the Alan Watts ideas that I love talking about is the law of reverse effort, which is to say the harder you try, the worse you make things. And I think it's very hard for product managers who pride ourselves on working very hard to accept this, but in a lot of cases, the harder we try the more we take in the worse we make things and the path to better product management often is more about letting go than this. Start digging in. Jason Knight 35:01 This is time to feel very zen again, as he said earlier. All right, like Bruce Lee, we like water. But one of the things I did like in the book was your idea. And I think you encapsulate in life, you're in some kind of an ideal situation like you're being top down, managed or overwritten, or told what to build or the classic things that PMS complain about. And yeah, we have to call out that sometimes that does go a bit too far. Like there's, it's not always that the pm needs to let go. Like sometimes they just worked for truly poorly run organisations. But let's put that to one side, like one thing that I did like is your idea that you shouldn't just get fed up and start fighting the system and fighting your bosses. But switch focus and relentlessly focus on your users and try to get success that way. Now, that obviously sounds super fantastic. And we should all be focusing on our users, because that's a big part of the product managers job, in some would argue the entire product manager's job. But I've also worked in places where it felt like it was actively being blocked from focusing on the users even so yeah. Is it as simple as just saying, if you're in a bad situation focused on your users, or is it a bit more complex than that? And are there other kind of ways to get through that type of situation where you might be being put into a defensive posture? Matt LeMay 36:11 Oh, nothing's ever that simple. Certainly, focusing on your users is always easier said than done. I hope that on some other podcasts right now, somebody is saying like, yeah, Matt's book just really oversimplifies what to do when you're because it does, right. Like, everything is necessarily over simplified. But I think, you know, again, personal experience is always a limiting factor in one's perspective. And I think I was writing largely from my own personal experience, where looking back, there were opportunities to shift focus, and I didn't take those opportunities, because I was so embattled, and I was so focused on, I didn't get that promotion, so I can't have the influence, I want the organisation or I, you know, this executive is trying to, for me, I was focused on the wrong things, and I could have focused on better things. Now, again, as you said, That's not always the case, you don't always have the opportunity to focus on other things. But looking back, honestly, on my own career, I have had those opportunities and made the most of them because I was so focused on the particular ways in which I thought I was being thwarted, or, you know, otherwise minimised or underappreciated by my organisation. So, you know, again, I think the big call out is, look for those opportunities, if you find yourself in a situation where you may have been so focused on your own position in the organisation, that you haven't necessarily look for those opportunities. Jason Knight 37:38 Absolutely. But one common complaint from those types of PMS, that maybe in some of those situations, is that they're stuck in a feature factory, you know, another bingo card phase for PMS these days? Sure. Am. I start waffling about outcomes over outputs, again, the rallying cry of the wannabe empowered product manager. But you talk about the outcomes and outputs you saw in the book? Yes, Matt LeMay 37:59 I'm still thinking about this so much these days. Jason Knight 38:03 So how does that concept help PMS? Matt LeMay 38:05 So this also came from this was like, to the minute when I was writing the book, like I think I cram this in in the last round of edits, because it was happening with a team I was coaching, where they kept saying outcomes over outputs, outcomes over output. But they kept coming back to outputs. And it's like, alright, well, what are the outcomes you're trying to achieve? And they're like, well, we want to get more conversions. I'm like, Well, how many by what they are like, ooh, scary. So the thing I found is that you need specificity to come from somewhere, you can't say we're going to do some stuff to make some numbers go up by some amount at some time. That makes people nervous. And rightly, so if you're an executive at a company, and pedagogical team says, Yeah, we're going to get more new users signed up. And we're gonna do it some way. That doesn't leave you feeling terribly confident. So the thing I found is that you need to get really specific about the outcomes you're trying to achieve need to say, this many users by this date, I keep cycling through the frame. And I used to say, you need to have high specificity, high altitude goals. I'm changing that to high specificity, high impact goals, like, because altitude is a confusing word, especially when I've been going around your app saying altitude, and people are like, Why are you talking about altitude? So I think I found that when teams commit, I just went through this with a team I was working with on a consulting engagement. This team is responsible for kind of cross boarding users from an old platform to a new platform. And they said, well, but we just keep being given features to build. I said, Okay, well, how many new users do you want to get on there? By what date? They said, well, we don't even know we can't really say, okay, end of q1 2023. Do you want to say, how many do you want to say, well, we don't know. We can't say it. I said, Alright. 10 100 or 1000? Somebody that, gosh, if we committed to 1000 we really have to focus on just building up the core platform here. We'd have to say no to a lot of requests. So there you go. There you go. 1000 So again, I think looking, really looking for that specificity on the order of outcomes. Again, if you think about it as a seesaw, you push down and get more specific on that side. And suddenly you have more freedom, you say, Well, okay, well, how do we get these users over here? Do we just send an email saying use this thing? Do we get more people hopping in? Do we switch everyone over in a mandatory way? Like, you start to ask those really important questions, and you start to realise that you probably have some levers to work with that aren't features. But that might involve working with the marketing team or working with sales or doing things that product teams might be more reluctant to do unless they have some good healthy pressure, compelling them to do so. So I think, you know, for me, it's not outcomes over output, it's like these two things are in the system with each other. And if you get more specific and ambitious about outcomes, you're probably going to have to get a little bit more clever about output, which is what presumably these teams want. Jason Knight 40:56 This reminds me, as he was saying about not being just outcomes, or just output was the it reminds me of the phrase from the Agile Manifesto that we, they're the things on the left, don't have no value, but just value the things on the right more, rather than it being a binary thing, which is, of course, the biggest problem that you see a lot of people with their agile absolutism. And I guess product absolutism in this case is like, it's not just one, it's somewhere along the line. And that position that you're on that line may change depending on the situation and the context. So you have on any particular day, or just in a particular company, I guess. Matt LeMay 41:30 Yeah. And I still, you know, I'll still do workshops, where I'm like, oh, we can't do how to code agile says you can have have documentation. And I'm like, it says right there, they're 60 words on this thing. And you've neglected like a fifth of them. So you know, again, everything, everything will always be misinterpreted, and selectively read, but that's human nature, Jason Knight 41:50 except your book except your book. Right? Except my except now, we can only set the product management is ambiguous, messy and noisy, and at the end of the day, quite hard. And you acknowledge this throughout the book, but in the foreword to the second edition, you say there's tremendous upside in the role as well. And you want to bring some positivity to it as well. Yeah. So what are some of the best things or maybe just pick one prioritisation? And what's the best thing about being a product manager as far as you're concerned? Matt LeMay 42:16 You're always learning new things. And that's phenomenal. Like you never, every time I feel like I've got this figured out, I know how to do this job, some new challenge presents itself when I realise, gosh, I have so much to learn. So I think if you are open to the idea of showing up to work every day, and learning something new, and facing a new challenge and working through a new problem, I'm hard pressed to think of a better role. Jason Knight 42:39 There you go growth mindset. Full speed ahead. And where can people find you after this if they want to chat more about product management, find out more about the book or see if they get any sartorial tips for that next big business meeting. Matt LeMay 42:52 Sure. So for sartorial tips, find me on Instagram, probably that's at MTT LM y where you go. If you want to talk product management, probably find me on LinkedIn. Or just go to Matt levine.com, or email me at Matt at Matt lemay.com. I am technically on Twitter, but I am probably going to deactivate any second and I'm not active on Twitter. So let's avoid the sunk cost fallacy as best we can. Yeah, always, always happy to hear from folks. Jason Knight 43:20 I will pop over to Instagram to get away from my black hoodie and jeans. All right. Well, I'll make sure to link that all into the show notes. Hopefully, you're going a few people heading in your direction to find out more. Matt LeMay 43:32 Fantastic. Thank you so much. Jason Knight 43:33 No worries. Well, it's been a great chat. So obviously, you're really happy to spend some time talking about the messy realities of Product Management. Obviously, we'll keep in touch. But as for now, thanks for taking the time. Matt LeMay 43:42 Thank you. Jason Knight 43:45 As always, thanks for listening. I hope you found the episode inspiring and insightful. If you did again, I can only encourage you to pop over to https://www.oneknightinproduct.com, check out some of my other fantastic guests, sign up to the mailing list, subscribe on your favourite podcast app and make sure you share your friends so you and they can never miss another episode again. I'll be back soon with another inspiring guest but as for now, thanks and good night.